【レポート】560万+ダウンロードのスマフォゲームインフラをAWSへ移行させたSREチームの工夫について #AWSSummit

AWS Summit Tokyo 2019

#レポート

#Amazon Aurora

#イベントレポート

#AWS Database Migration Service

#AWS

渡辺聖剛

2019.06.14

この記事は公開されてから1年以上経過しています。情報が古い可能性がありますので、ご注意ください。

水曜よりより開催されています AWS Summit Tokyo 2019。こちらで開催された株式会社サムザップ様によるパートナーセッション L3-01 をレポートします。

あるSREチームの挑戦運用6年目の大規模ゲームをAWS移設後に安定運用するための技術と今後の展望

「戦国炎舞 -KIZNA-」はサービスの立ち上げから約6年間に渡ってオンプレミス環境で運用しており、以下のような課題がありました。
・肥大化したデータとログ
・1日に3回あるゲーム内イベントの時間に大幅に増量するリクエストへの柔軟な対応
・自動化しづらい構成と環境
これらの問題を解決するためのAWS移設でしたが、レスポンス速度の改善、コスト低減、運用効率の改善など多くの成果を上げることができました。移設の目標と共に、どう課題解決したかと今後の展望についてをご紹介します。

資料

（後日公開されるとのことです）

内容

自己紹介
- 石原裕之 SREチームマネージャ
  - 好きなサービス : Aurora 性能が良い、管理が楽
- 吉岡賢 TechLead
  - 好きなサービス : Route53 SLA100%
サムザップのSREチーム
- インフラチームから名称変更
- ゲームサービス
- 機能開発は行わないが、安定性の向上やパフォーマンス改善などに繋がる開発は行う
サムザップの事業内容
- CA子会社
- スマフォゲーム
  - リンクスリングス
  - 戦国炎舞 -KIZNA- <- 本日話すこと

戦国炎舞 -KIZNA-

戦国炎舞 -KIZNA- | 株式会社サムザップ
- 560万ダウンロード
- プライベートクラウドからAWSへ 2月
- 200+インスタンス
- 23000req/sec
- 合戦というリアルタイムイベントが一日 3 回
「合戦」にアクセスが集中
- 平時の10倍〜20倍
- これが毎日3回発生
構成
- 以前はプライベートクラウドで構築していた
- AWS
  - Web EC2
  - 課金情報などはAurora
  - memcacheクエリキャッシュ
  - redis合戦中の行動に必要なポイント情報など
  - 画像はCloudFront
移設の背景　なぜプライベートクラウドから移設することになったか
- プライベートクラウドの一部提供終了がきっかけ
- AWSを選んだ理由 = Auroraがあるから
  - 多数のDBサーバのトラブルを減らしたかった
  - 旧環境で苦労
  - 他にもマネージドサービスがあったりコストの問題も

旧環境での課題と解決方法

旧環境での課題1

合戦前後で柔軟なサーバ増減させたい
- 旧環境では事情があってできなかった（APIエラー増大等
AWSでは
- CloudWatch Eventsで時限トリガー
- Step Functionsを呼び出すLambdaが実行される
- 合戦用のASGに増設・停止をスケジューリング
- slackへ増設の開始を通知
- 自動でインスタンス増設・サービスイン（ELB参加など
費用比較は単純ではないが、常時起動よりは1/3程度になっている
副次的効果
- マシン性能が上がり応答速度がアップした
  - レスポンスタイムが1/3 <- C5
  - インスタンスタイプを柔軟に変更できるのも良い
今後
- SpotInstanceの導入を検証中、来月には検証完了予定
  - 試算だとさらに50%下がる

旧環境での課題2

肥大化したデータとログ
DBサーバの運用、管理に疲弊 -> DB性能5倍、複数DBを集約
- 78台 -> 10クラスタ 20インスタンスにできそう
- ディスク容量 -> 64TBまでいける
- トラブル時の対応 -> 自動でfailover
Auroraへのデータ移行はDMSを選択
- AWS Database Migration Service（最小限のダウンタイムでデータベースを移行）| AWS
- DSM選択の理由 = Auroraへの移行と集約を同時に実現するため
- DSMはEC2上のレプリカDBから
  - レプリカDBはプライベートクラウド上のDBと同じ台数
  - 直接MySQLデータを読み取ろうとすると回線(10G)を使い切ってしまい速度が出なかった
  - AWS内で全ての処理を完結できるように
  - データ数TBを6時間
検証中に苦労したポイント
- 動作検証チャンスは1日1回
  - 退社前にタスクをセット、翌朝確認
- レプリケーションインスタンス台数とスペックの調整
  - CloudWatchを見ながら（地道
  - 最終的にr4.8xlarge x20
- DSM分割数の調整
  - 6億レコードをひとつだと、1日で移行が終わらない
  - 1億件ごとにタスクを分割（8hに収まるように計算）
手間のかかるアプリログの調査
- gzipで36GB/day
- 調査に数十分〜数時間
- 移設後はS3に保存、Athenaで調査
  - ダウンロード不要に
  - 調査は数秒〜
  - 提携調査は社内ツールを整備

旧環境での課題3

自動化しづらい構成と環境
なぜ自動化したいのか？
- NoOpsを実現するため
  - トイルをなくして安定稼働させるための改善に使う時間を確保
旧環境：自動化しづらい構成と環境
- 外部サービスとの連携がしづらい
- ロール管理ができない、効率の悪いdeploy対象管理
- マーケティング用分析基盤の扱いが職人化した
やったこと
- デプロイ自動化
- 画像のデプロイ自動化
- アプリケーションソースデプロイ
- 分析基盤

デプロイ自動化

デプロイしたいファイル：アセットバンドル、画像、ソースコード
「アセットバンドル」とは
- ランタイムに読み込むデータのアーカイブのこと
  - モデル、テクスチャ、オーディオデータ　…
- 移設前
  - アプリケーションバージョンとアセットバージョンの対応情報をソースで管理
  - 移設後は自動でアップデートされるようにした
- buildシーケンスの管理はJenkins
- S3アップロードをトリガーにLambdaをキックしてDBにバージョン情報をインサート
- アプリケーションが対応のバージョンを起動時に確認してCDN経由でダウンロード
  - アセットバンドルだけ管理すれば良くなった

画像のデプロイ自動化

パスのハッシュかが必要
- 新しく配信する画像のパス(URL)を予想させないため
- 動的に配信していた
  - CDNでキャッシュ、オリジンはEC2 -> DB
  - オリジンサーバの保守管理が大変
- 移設後は静的に変更
  - あらかじめハッシュ化された名前で画像ファイルを置いておく（S3
  - git pushをトリガーにCI runnerがS3へアップロード
    - リネームしてオリジン用に置き直す（Lambda

アプリケーションソースデプロイ

移設前と比べて最大 1/9に短縮
6年続いているゲームサービスなのでレガシーが残っていた
- scp, rsync
移設後は並列pull型、タグによる自動判別
ロールのタグさえ付け間違えなければ運用管理可能になった
ソースコードに依存していたmemcache接続情報
- AWS移行後はAPIから読み出してマッピング
- consistemnt hashingなので障害時でもメンテ不要
- AWS APIでクラスタ情報を読む際に、APIのRate Limitを超えないようにRedisにキャッシュ
- webサーバのローカルキャッシュにも持つ